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Att ett system har god förvaltningsbarhet (maintainability på 
engelska) innebär att det är lätt att underhålla, det vill säga att det 
är lätt att rätta fel i systemet och det är lätt att ändra och lägga till 
funktionalitet. Den här artikeln, som jag skrivit tillsamans med 
Magnus Österlund från Ida Infront, ger råd och tips om hur man får 
med rätt krav på förvaltningsbarhet i kravspecifikationer. 


Att se till att ett system har hög förvaltningsbarhet är nyttigt redan 
under utvecklingsfasen, efter att den första raden programkod är 
skriven gör samma egenskaper systemet både enklare att 
utveckla och att förvalta. Trots detta finns det inga garantier för att 
utvecklingsprojekt alltid levererar system som är lätta att förvalta. 
Förvaltningsbarhet är dessutom en egenskap som är mycket svår 
att lägga till i efterhand. Därför anser vi att krav på 
förvaltningsbarhet är en viktig del av kravspecifikationen för nya IT- 
system. 


Med krav på förvaltningsbarhet menar vi alla krav som syftar till att 
det ska vara lätt att rätta fel, ändra funktionalitet och lägga till ny 
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funktionalitet i systemet efter att det tagits i drift. Vi tänker här 
redogöra för våra erfarenheter från en fallstudie om hur krav på 
förvaltningsbarhet hanteras idag, samt ge ett antal råd om hur krav 
bör ställas för att ge mer förvaltningsbara system i framtiden. 


Nuläget i teori och praktik 


Vi har genomfört en fallstudie av hur krav på förvaltningsbarhet 
behandlas i riktiga kravspecifikationer. Som underlag för fallstudien 
har vi även studerat litteraturen, i form av läroböcker, 
forskningsartiklar och processer. Slutsatserna kan kort 
sammanfattas som att alla tycker att det är viktigt att ställa krav på 
förvaltningsbarhet, men att det inte finns något konsensus om hur 
det bör gå till. 


Fallstudien har utförts på kravspecifikationer från ett tiotal svenska 
myndigheter, som under perioden 2003-2004 genomfört offentliga 
upphandlingar angående nyutveckling av IT-system. 
Kravspecifikationerna granskades med målet att ta reda på hur 
vanligt det är med krav på förvaltningsbarhet, vilken typ av sådana 
krav som ställs och hur de formuleras. 


Fallstudien visade att alla de studerade kravspecifikationerna 
innehöll någon form av krav på förvaltningsbarhet, vilket vi tolkar 
som ett utbrett intresse för god förvaltningsbarhet bland de 
kravställande myndigheterna. Vi fann dock att det finns utrymme 
för förbättringar av hur kraven ställs. För det första utnyttjar 
flertalet kravspecifikationer inte det breda spektrum av möjligheter 
som finns för att specificera förvaltningsbarhetskrav. För det andra 
är många av de krav som finns dåligt formulerade. De flesta 
kraven är inte testbara till följd av vaga formuleringar eller 
svårtolkade krav. Några exempel: 
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e "Förändringar bör kunna göras på ett enkelt sätt" 


e "Systemet ska stödja tillägg och ändring av funktionalitet utan 
nämnvärda designändringar" 


e "Spelet ska vara enkelt att bygga vidare på för framtida utveckling" 


Tabellen nedan visar vilka typer av förvaltningsbarhetskrav som 
ställdes på systemen. Varje rad i tabellen visar vilka krav som 
ställts på ett specifikt system och som rubrik för varje rad finns en 
mycket övergripande beskrivning av systemet. Varje kolumn 
representerar olika områden inom vilka man kan ställa krav på 
förvaltningsbarhet. Vad de olika områdena innebär beskrivs nedan, 
under rubriken "Checklista med kravkategorier". En cirkel visar att 
det fanns krav inom området. I de fall kraven var försumbara, 
genom att bara något enstaka vagt eller väldigt "smalt" krav finns, 
är cirkeln ofylld. 


uonesiueB.o 


Realtidssystem för 
PDA:er 


Fakturerings- 
system 


Informations- 
nätverk 


Integrationslösning 


Fartygsrapport- 
eringssystem 
System för 
miljöavgifter 
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Hela fallstudien beskrivs utförligt i en artikel (här är artikeln som 





pdf-fil) som vi publicerade på konferensen SERPS. 


Sammanfattningsvis visar alltså både litteraturen och verkligheten 
på ett utbrett intresse för förvaltningsbarhet, men det tycks vara 
brist på handfasta råd om hur man ställer krav för att få 
förvaltningsbara system. Vi tänkte försöka angripa den bristen. 


Generella råd till kravställare 


Vi anser att den viktigaste förutsättningen för att lyckas ställa 
relevanta krav på förvaltningsbarhet är att som kravställare vara 
medveten om att denna aspekt finns och ska behandlas i 
kravspecifikationen. Användbarhet och säkerhet är andra sådana 
aspekter, som redan idag får ganska stort fokus i kravarbetet. 


Det är viktigt att sätta ambitionsnivån. Hur viktig är 
förvaltningsbarheten är för systemet? Ofta underskattas den - 
system får ofta längre livslängd än planerat. Dessutom gäller att 
om förvaltningsbarheten är god är det större chans att systemet 
kan bli långlivat och därmed kostnadseffektivt. Men det är inte så 
enkelt att högre förvaltningsbarhet alltid är bättre än låg dito. Det 
kan kosta tid och pengar att göra systemet lättunderhållet och 
ibland är leveranstid och låg initialkostnad viktigare. Rådet blir 
därför ganska allmänt hållet: tänk till och gör ett medvetet val av 
ambitionsnivå för systemets förvaltningsbarhet. Låt sedan detta 
styra kravarbetet på området. 


På samma sätt som när man arbetar med andra sorts krav är det 
viktigt att involvera verksamhetsexperter. Verksamhetsexperter för 
förvaltningsbarhetskrav är i första hand personer från 
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förvaltningsorganisationen. De har värdefull kunskap om 
arbetssätt, kompetens, etc. Det är även viktigt att från 
användare/beställare inhämta kunskaper om ifall det finns delar av 
systemet som kan förväntas bli mer utsatta för ändringar och om 
det finns några specifika ändringar som ska förberedas för när 
systemet utvecklas (mer om detta under "Specifika 
förvaltningsbarhetskrav" nedan). 


Det är bra om syftet med varje krav är tydligt. Det gör 
kravspecifikationen tydligare och minskar risken för missförstånd. 
Ett enkelt sätt att åstadkomma detta är att lägga alla krav som 
syftar till att specificera förvaltningsbarheten för systemet under en 
speciell rubrik. 


Checklista med kravkategorier 


Det finns en mängd sätt att ställa krav på förvaltningsbarhet. Här 
presenterar vi 10 kategorier som man kan ställa krav inom. Alla 
sätt passar inte för alla system och för de flesta system behöver 
långt ifrån alla kravkategorier användas. Vi rekommenderar att 
använda listan som en checklista. Gå igenom varje kategori och 
tänk efter om det finns något som är relevant för systemet att ställa 
krav på inom kategorin. Välj "era" kategorier utifrån typ av 
förvaltningsorganisation, etc. 


. Dokumentation. Dokumentation över hur systemet är designat 


och implementerat kan vara mycket värdefull när man ska utföra 
underhåll på systemet. Man kan ställa krav på dokumentationen, 
till exempel genom att ange vad som ska dokumenteras, hur det 
ska beskrivas (notationer, språk) och tekniska format för den. 


2. Arkitektur och design. Systemets arkitektur och dess design 
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påverkar förvaltningsbarheten och därför kan det vara relevant att 

ställa krav på dessa. Vissa arkitekturer och designmönster hävdas 
ge högre förvaltningsbarhet, som t.ex. abstract factory pattern. Att 

konsekvent använda samma mönster i olika delar av systemet kan 
öka förvaltningsbarheten. 


. Källkod. Krav på att systemets källkod ska följa 


kodningsstandarder och krav på kommentarer i källkoden kan ha 
en positiv påverkan på förvaltningsbarheten. En viktig faktor som 
påverkar förvaltningsbarheten är källkodens komplexitet. 
Komplexitetsmetriker kan användas för att specificera en 
acceptabel nivå. 


. Tredjepartsprodukter. Många produkter från 


tredjepartsleverantörer behövs för att skapa IT-system, till exempel 
programmeringsspråk, databaser och operativsystem. Ibland kan 
det vara relevant att ställa krav på sådana produkter för att 
förbättra förvaltningsbarheten. Om underhållsorganisationen 
består av erfarna Java-programmerare är det relevant att kräva att 
systemet skrivs i språket Java. 


. Testfall. Att ha en uppsättning regressionstestfall kan vara ett sätt 


att minska risken att introducera fel när systemet förändras. Därför 
kan det vara relevant, av förvaltningsbarhetsskäl, att kräva att 
sådana testfall levereras med systemet. 


. Körande system. Det kan vara relevant att ställa krav på hur det 


körande systemet får påverkas av förändringar. Sådana krav kan 
specificera vilken grad av tillgänglighet man kräver av systemet 
när förändringar görs. 


. Underhållsorganisation. Ett sätt att hantera förvaltningen är att 


låta någon annan göra det, det vill säga att kräva att systemet 
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levereras med förvaltningstjänster. Krav kan ställas på hur sådana 
tjänster ska vara utformade. 


. Process. Man kan ställa krav på processen som ska användas för 


att utveckla systemet. Antingen genom att kräva att någon 
utvecklingsprocess som hävdas ge lägre förvaltningskostnader 
används (exempelvis Extreme Programming), eller genom att 
ställa krav på enskilda aktiviteter, som till exempel inspektioner 
med fokus på förvaltningsbarhet. 


. Systemövergripande. Det går att ställa systemövergripande krav 


på hur förvaltningsbart systemet ska vara. Exempel på sådana 
krav är hur mycket arbete som får krävas för olika typer av 
förändringar. 


Ägande. För att över huvud taget kunna utföra förändringar i 
systemet är det viktigt att ha legala möjligheter att göra det. Krav 
kan ställas på att källkod och dokumentation ska ägas av kunden 
eller att licensrättigheter åtminstone tillåter förändringar. 


Specifika förvaltningsbarhetskrav 


Ibland vet man redan vid utvecklingen av ett system att några 
specifika förändringar kan komma att behövas i framtiden. Kanske 
har man skäl att tro att systemet i framtiden behöver stödja flera 
valutor, eller att det kommer att behöva användas via Internet. Det 
är vanligt att kunna förutse sannolika framtida förändringar som 
man ändå inte vill ha med vid utvecklingen för att den ska bli 
billigare, snabbare eller helt enkelt för att man vill låta 
organisationen använda systemet en tid innan man bestämmer om 
förändringarna behövs. Krav som handlar om att beskriva 
tänkbara framtida förändringar, så att systemet redan från början 


about:reader?url=https%%3A%2F%2Fweb.archive.org%2Fweb%2F2006... 


2021-11-04 15:56 


Effektiv förvaltning börjar i kravspecifikationen about:reader?url=https%%3 A%2F%2Fweb.archive.org%2Fweb%2F2006... 


8 av 12 


kan vara förberett för att förändras kallas specifika 
förvaltningsbarhetskrav. 


För att ett specifikt förvaltningsbarhetskrav ska vara bra räcker det 
inte att det beskriver en tänkbar framtida förändring. Kravet måste 
även beskriva hur väl förberett systemet ska vara för förändringen. 
Det är till exempel stor skillnad på att en förändring är tekniskt 
möjlig och att förändringen ska kunna göras genom några enkla 
inställningar i en parameterfil. Några exempel på specifika 
förvaltningsbarhetskrav: 


e Alla texter i systemets användargränssnitt skall kunna bytas ut 


genom att ändra i en textfil. 


Införande av konceptet "bonuskund" som har en personlig 
rabattsats kopplad till sig skall kunna göras utan att systemets 
databasschema behöver ändras. 


Systemet skall kunna förändras för att stödja följande tänkbara 
framtida krav, utan några förändringar i telefonimodulen: 
rapporterna ska kunna visas på mobila enheter, lönetillägg ska 
kunna baseras på personlig försäljning. 


Det är alltså viktigt att varje specifikt förvaltningsbarhetskrav 
beskriver hur väl förberett systemet ska vara för en viss förändring. 
Lämpligen uttrycker man detta i termer av vilken påverkan på 
systemet förändringen skulle ha om den genomfördes. Det finns 
ett stort antal varianter av påverkan, exempelvis: 


Förändringen skall kunna utföras utan att systemets källkod 
behöver ändras eller utökas. 


Förändringen skall kunna utföras utan att systemets källkod 
behöver ändras. Ny källkod får dock läggas till (och anrop till den 
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nya koden får läggas till i befintlig kod). 


Förändringen skall kunna utföras utan att några förändringar 
behöver göras i systemets kompilerade enheter. Nya kompilerade 
enheter får dock läggas till. 


Förändringen ska kunna utföras utan att systemets 
databasschema behöver ändras. 


Förändringen skall kunna utföras utan att systemets klientmoduler 
måste ändras. 


Ingen ändring alls, dvs. systemet ska redan ha funktionen inbyggd, 
men det ska gå att köra systemet utan att använda den. Det här 
betyder att det inte är fråga om något förvaltningsbarhetskrav utan 
ett normalt funktionellt krav. 


Vårt råd är att se till att få med relevanta specifika 
förvaltningsbarhetskrav i kravspecifikationen och att låta dem 
bestå av både vad som ska ändras och på vilket sätt systemet får 
påverkas. 


Generella förvaltningsbarhetskrav 


Generella förvaltningsbarhetskrav är krav som syftar underlätta 
oförutsedda förändringar (till skillnad mot specifika 
förvaltningsbarhetskrav, där förändringarna är förutsedda). Vi 
anser att många generella förvaltningsbarhetskrav kan 
standardiseras och katalogiseras för att sedan återanvändas för 
flera system. Vi har gjort en sådan katalogisering av ett antal 
generella förvaltningsbarhetskrav. Här är några exempel på krav 
från katalogiseringen: 


e Kodningsstandard. Källkod som skrivs i programmeringsspråket 
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X skall följa kodningsstandarden Y. 


Automatisk byggmiljö. Med systemet skall en komplett byggmiljö 
levereras. 


Källkodsspråk. Identifierare och kommentarer i källkoden skall 
vara på engelska. 


Klientdistribution. Funktioner för centralt administrerad 
uppdatering av kod på klienter skall finnas. 


Vid katalogiseringen bör kraven dokumenteras på ett sätt som gör 
det lätt att förstå vilka konsekvenser det får att ställa kravet och på 


vilka sätt det är rimligt att anpassa kravet för det aktuella systemet. 


Nedan följer ett exempel på ett sådant återanvändbart 
standardkrav. 





Regressionstestfall 





Kravtext 

Systemet skall levereras tillsammans med automatiserade 
regressionstestfall. När testerna startats skall ingen mänsklig 
inblandning behövas innan resultatet rapporteras. Som resultat 
av testerna skall en rapport som visar vilka testfall som är 
uppfyllda respektive inte uppfyllda skapas. Testfallen skall ge 
satstäckning (eng. statement coverage) på minst 80%. Alla 
verktyg som behövs för att köra testerna samt instruktioner för 
hur testerna körs skall levereras med systemet. 





Förklaring 

Ett stort problem vid förändring av mjukvara är att det är lätt att 
av misstag föra in fel utan att upptäcka att man gjort det. Tack 
vare att regressionstestfallen är automatiska är det lätt att utföra 
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testerna när en förändring gjorts och på så sätt kan man 
upptäcka fel som råkat komma med. Naturligtvis är det ingen 
garanti för att alla fel upptäcks, men det är en klar förbättring 
jämfört med att inte ha några automatiserade regressionstestfall 
alls. 

Att testfallen skall ge satstäckning på minst 80% innebär att 
80% av satserna i programmet måste köras av minst ett testfall. 
Detta kan tyckas vara lite, men i praktiken är det svårt, och 
därför dyrt, att kräva mycket hög satstäckning. 





Kostnad 

Att använda automatiserade regressionstestfall är att 
rekommendera för i princip all systemutveckling eftersom det 
förenklar utvecklingsarbetet på så sätt att fel i systemet hittas 
tidigare. Det förekommer därför att utvecklare använder sådana. 
Kostnaden att skapa automatiserade regressionstestfall är 
relativt hög, men nyttan för någon som ska underhålla systemet 
är även den relativt hög. 





Anpassningar 

Man kan välja olika procentsats för satstäckning. Vi 
rekommenderar en procentsats i intervallet 70-95%. Högre 
satstäckning än 95% kan bli mycket dyrt eftersom det är svårt 
att i praktiken skapa testfall som kör all programkod. 

Det finns flera alternativa mått på hur stor del av programkoden 
som genomlöpts av testfallen. Satstäckning har fördelarna att 
vara lätt att definiera, lätt att mäta och att vara tämligen neutral 
för vilket programmeringsspråk som används. 

Vi rekommenderar inte att nöja sig dokumenterade testfall som 
kan utföras manuellt, eftersom den stora nyttan med 
regressionstestfall vid underhåll av systemet kommer av att det 
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är snabbt gjort att köra dem efter varje förändring som gjorts. 





Relation till andra krav 

Instruktionernas utformning påverkas av eventuella generella 
dokumentationskrav. 

Som krav på tredjepartskomponenter kan man kräva att 








speciella verktyg ska användas för testerna. 





Skicka gärna kommentarer till mig. Adressen är 
jens@jensgustavsson.se. 
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